Why not simply swap contents for moving ops btw? Should be cleaner and shorter code overall. Also no need to check for this etc. in such instance.

I believe it was @wopss who wanted it this way, as it doesn't introduce any complexity

I don't remember complaining about this. I also don't get why we don't do std::swap.

I dont like allowing negative values, shouldnt be the case for proper range. Only case this should ever return negative is for random access range where you swapped first and last, shouldnt affect reverse iterators on the range AFAIK.

Im actually unsure if we should even care for distance, IMO for generic case like this when iterators/range isnt random access, it should just use back_inserter, this may introduce tons of unwanted overhead. Iteration over some types isnt fast, and iterating through it twice unnecessarily may bottleneck things unless it is random access range as mentioned.

How do you suggest I avoid the double evaluation?
I assume it involves changing the template concept to std::forward_iterator?

No, use std::back_inserter instead of directly using begin/end for copying. And preallocate space only when you have std::random_access_iterator via reserving and not resizing. For std::random_access_iterator, std::distance is constant operation.

Would std::back_inserter work like you suggest? DynArray doesn't currently (STL semantically) define push_back

It wouldnt that is true, there should be push_back also in the STL portion of the containers, along with value_type typedef so you can use std::ranges::value_type

Also, I believe we already do have an overloaded operator[] right? That is sort of a key for random_access_iterator to be valid, all iterators that are for random access containers should also have an operator+ for that.

Im missing some way to assign range directly, we are long past the age of having to use iterators unless absolutely necessary. Can achieve practically everything with ranges and views more cleanly.

Applies to constructors also.

Missing some move-assignment.

What are you suggesting here? Should I create a new method to accept a range, or adjust this one? If it's the former, what structures are implied by ranges and views?

New method ideally which accepts any range as a type. Ranges have to have begin() and end() defined, other functions like empty() and size() are not guaranteed unless you go to specializations of ranges.

It likely would end up as a wrapper for iterator-based assignments.

I dont think std::forward is correct in this instance. Likely wont cause an issue but that is more thanks to its definition, shouldnt be ever needed when you know you are passing lvalue reference.

This almost certainly seems wrong, forwarding && will always result in rvalue reference even when it formerly wasnt. Just ValueType should be enough.

I don't even see the need of std::forward here, a simple std::move should be enough.

They are not the same, && also eats const &, when you move instead of forward, that info is lost and leads to undefined behaviour. In this instance, it should be forward as you forward the argument further down the pipeline.

Issue is primarily wrong function overload may get called in an instance I tried to make an example of if you use wrong one.

std::destroy_at

This shouldnt be needed provided NOMINMAX macro is correctly defined. And if you are worrying about this, rather wrap min and max keywords in parenthesis eg. std::numeric_limits<SizeType>::(max)()

I would be against providing NOMINMAX macro since others might not like it when this library is used in their code.

Believe it is pretty universal tbh, and you already do WIN32_LEAN_AND_MEAN I believe but would have to double-check. Unless in C, those macros are pointless and just cause issues like the above to appear. Macro is kept only for backwards compar am fairly certain and safe to provide. Always can be undefed by user.

Id be for this still.

And here you dont check the size and make it absolute and whatnot. Just as a note to the other distance comment I had, negative values are practically never a good sign.

I just thought about this, but removing this header and class will cause a lot of issues. So, I propose to add it back, deprecate them (the header and the class).

What kind of issues? The changes already include updates to all the DynArray file paths, and Reflection-inl.hpp was updated accordingly for the dumper

People project's still use this path, changing it like that will be a breaking change.

Simplest solution to this - just have file in original location including the file from right location.

Isnt likely as clean, but should be more than sufficient imo not @wopss ?
Also the least amount of additional changes.

Exactly. And add a pragma message in the header saying that it is deprecated.